Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（後編）

はじめに

本記事は、全９回の SRE 社内勉強会のアウトプットとして執筆したブログの後編となります。 前編をお読みでない読者の方がおられましたら、是非前編もご一読ください。

５章　トイル（労苦）の撲滅

「通常運用中のシステムに人手が必要なら、それはバグだ。通常の定義は、システムの成長と共に変化する。」

トイルを減らしサービスをスケールさせる作業こそが SRE における「エンジニアリング」である点を説明しています。聞き慣れない言葉ですが、トイルとは何でしょうか？ここでは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向をもつものと述べられています。例えば、以下の説明の１つ以上に当てはまるような仕事であれば、その仕事のトイルの度合いは高いと言えるようです。

• 手作業であること
• 繰り返されること
• 自動化できること
• 戦術的であること（緊急対応により呼び出されるような作業は、トイルです。この種の仕事を完全に無くしてしまうことは出来ませんが、最小限になるよう継続的に努めなければなりません。）
• 長期的な価値を持たないこと
• サービスの成長に対して O(n)であること

普段行っている作業の中で、上記項目の１つ以上に当てはまるような仕事はありませんか？ 以下に示す項目に該当しない場合、そのような仕事は可能な限り自動化を行い減らしていくべきです。

• サービスを稼働させることに直結していない管理的な作業（例えば、採用、ミーティングや、ゴールの設定と評価、スニペット、人事の事務作業、自己評価やトレーニングなど長期的な価値のある作業）
• 繰り返しのない少量でかつ楽しめる作業（低リスクで、ストレスが少なければトイルを多少含んでいたとしても問題にはならない。ただし、大量に処理しなければなくなった場合にエンジニアリングを行います）

Google の SRE チームでは、各個人の運用作業（つまりトイル）を 50% 以下に抑えるという目標が掲げられているようです。（50%ルール）つまり、残りの半分はエンジニアリング作業に費やされるべきだと考えられています。Google の四半期ごとの調査によるとトイルに費やされている時間は、平均 33% と報告されており目標値よりもかなり下回っていますが、エンジニアによって 0% の SRE もいれば 80% の SRE も存在しているようでマネージャーは、均等にトイルの負荷を配分できるよう促さなければならないと述べられています。

この章が勉強会を開催していた中でも、一番共感が得られた章だったように思われます。

６章　分散システムのモニタリング

モニタリングおよびアラートのシステムをうまく構築するための基本原則とベストプラクティスが述べられています。モニタリングにおける４大メトリクスは、以下であると述べられています。

• レイテンシ
• トラフィック
• エラー
• サチュレーション

また、アラートを発生したシステムが自身を自動修復できない場合は、人間がそのアラートについて調査を行い、本当に問題があるのかを判断し、問題に対処した上で、問題の根本原因を判断する必要があるため、無闇矢鱈とアラートを発生させるシステムは当然ながら問題である点が述べられており、人間へのアラートを発生させるルールは、理解しやすく、明確な障害を表現するものであるべきと書かれています。 結論として、モニタリングシステムは可能な限りシンプルな設計を行うのが良い点や、以下のような原則についてをとりまとめられています。

• アラートに対する緊急度は適切か？
• アラートに対するアクションは、安全に自動化できるか？
• アラートに対するアクションは、対処策（長期的な修正効果を持つか？）か、回避策（一時的な対処）か？
• アラートを受け取るエンジニアは、複数人必要か？
• 緊急の呼び出しは、対応に知性が必要なものか？（ロボット的なレスポンスを返すだけなら、そもそも緊急の呼び出しにすべきものではない）
• 緊急の呼び出しは、新たな問題もしくは、これまでに見られたことがないイベントに関するものであるべき

７章　Google における自動化の進化

「暗黒芸術を除けば、そこにあるのは自動化と機械化だけだ。」

自動化の価値と、Google における自動化に対する姿勢の進化について説明されています。 当たり前かと思われますが人間が手作業によりタスクを処理することで、間違いや見逃し、データ品質の問題や信頼性の問題が生じると述べられています。 また、DB クラスタのフェイルオーバーを例に挙げ自動化の進化は、以下の経過を辿る旨が記載されています。

• 自動化以前（フェイルオーバーが手動で行われる状態）
• 外部でメンテナンスされるシステム固有の自動化（SRE 個人がフェイルオーバーのスクリプトを保持する状態）
• 外部でメンテナンスされる汎用の自動化（誰でも使える「汎用フェイルオーバー」スクリプトに、SRE が DB サポートを追加した状態）
• 内部でメンテナンスされるシステム固有の自動化（DB 自身にフェイルオーバーのスクリプトが同梱されてリリースされた状態）
• システムが自動化を必要としない（DB が問題を検出し、人間の介入なしに自動的にフェイルオーバーを行う状態）

そして、最終的なゴールとして「何もかも自動化する」という次のレベルへ進めることになったと書かれています。 具体的には、Google のクラスタスケジューリングシステムである Borg 上に MySQL を移行することを検討し、移行するまでの経緯などが記されています。 Borg 上に MySQL を移行することによりすべてのアプリケーションに対する修正なども必要となったようですが、最終的には SRE チームが日常的な運用タスクに 費やす時間の 95% が削減されたようです。また、その結果として物理マシンのリソース使用率が最適化されハードウェアの使用率が 60% 解放出来たという事実が 記載されています。締めくくりの言葉として、「自動化のすすめ」が記載されており Google のような規模でなくとも、自動化を行うメリットがある点を述べています。

８章　リリースエンジニアリング

CI/CD の重要性を記しています。リリースエンジニアリングは、Google 社内においても明確な１つの職能と位置付けられ リリースエンジニアは、プロダクト開発に携わると共に SRE と共同で以下の項目を規定する旨が記載されています。

• ソフトウェアのリリースに求められるソースコードリポジトリへのソフトウェアの格納方法
• コンパイルのためのビルドのルールや、テストの方法
• パッケージング、デプロイの進行といったすべてのステップ

８章を読み進めて行くと、Google で利用されている以下のようなシステムやツールなどの説明が続きます。

• リリースシステム
• ビルドツール
• ブランチ戦略
• テスト
• パッケージ化
• デプロイメント
• 設定管理

まとめとして、この章は Google だけに限った話ではないこと、リリースエンジニアリングは初期の段階から始めるのが良いということなどが記されています。

９章　シンプル（翻訳本では、「単純さ」）

「そうして費用をいくらつぎ込んでも、信頼性だけは手に入らない。信頼性は、極限まで単純さを追求することでしか手に入らないのだ。」

様々なものを単純にすることで得られるメリットについて記されています。文中の Google エンジニアである Robert Muth さんの言葉を借り述べられた一文が、とても印象的でした。 「物語とは違い、スリルやサスペンス、謎解きがないことこそ、ソースコードの望ましい姿なのです。」

また、プロダクション環境における予想外の出来事は、SRE にとって難敵であり想定外の複雑さを 最小限にするために、SRE チームが以下の項目を実施していることが述べられています。

• 受け持っているシステムに想定外の複雑さが生じていたら差し戻す
• 関わっているシステムや、運用を受け持つことになるシステムから複雑さを取り除く努力を継続的に行う

続いて git のようなバージョン管理システムをうまく活用し、シンプルなソースコードを維持し続ける努力を惜しまないことが記されています。 「9.5 最小限のAPI」にはフランスの詩人 Antoine de Saint Exupery の以下の言葉が引用されています。 「最終的に完璧なものが生まれるのは、追加するものがなくなったときではなく、取り除くものがなくなったときである」

最後に「単純な結論」として、ソフトウェアを単純にすることは、信頼性を持たせるための前提条件だということを強く強調しています。

さいごに

全９回の勉強会に参加し、９章までを読んだ率直な感想としては SRE という役割を担うにはまず考え方を改める必要があるのかな？という疑問でした。 Google が管理するような規模のシステムを運用しているわけではないため、SRE 本に記された内容がそのまま自分たちのビジネスに適用するとは思えません。 でも、この本に記載されている考え方やエッセンスみたいなものは自分たちのビジネスにも取り込むことが出来る余地があるような気がします。

弊社のオペレーションチームが担う役割だと、５章　トイルの撲滅が最も身近でありかつ共感を誘う章でした。 Google では扱うシステムが一般的な会社のシステム規模と比較しようもない大きさになっており、その背景の中から生まれた 新しい SRE という役割が必要不可欠だったんだと想像します。しかしながら、これからの時代システムの規模に関わらず SRE という新しい役割や考え方が浸透し、一般的になってくるんじゃないかな？と妄想を膨らませます。

取り留めの無い文章で締めくくりますが、この勉強会を通じて SRE という考え方や、エッセンスを学ぶ事が出来たのかなと感じました。 今後、クラスメソッドのオペレーションチームが SRE チームになれるよう日々精進していきたいと思います。

ではでは